Application No. 10/087,184 
Amendment Dated: October 24, 2005 
Reply to Office Action of April 22, 2005 

REMARKS 

The above amendments are made in response to the first Office Action mailed April 22, 
2005, wherein: 

1 . The Specification was objected to on the basis of not having a brief description of 
FIGS. 8a-8f as shown in the drawings filed June 17, 2003; 

2. Claims 26, 27, and 29-34 were rejected under 35 U.S.C. § 102(a) as being anticipated 
by the article by Braun, et ai, entitled "Management of Quality of Service Enabled 
VPNs," IEEE Communications Magazine, May 2001 (the "Braun article"); 

3. Claims 1-3, 5-1 1, 13-25, 28, and 35 were rejected under 35 U.S.C. § 103(a) as being 
obvious of the Braun article in view of U.S. Patent No. 5,038,318 to Roseman (the 
"Roseman patent"); and 

4. Claims 4 and 12 were rejected under 35 U.S.C. § 103(a) as being obvious over the 
Braun article in view of the Roseman patent, and further in view of the article by Barr 
entitled "Using Graphs to Explore Databases and Create Reports," SIGCHI Bulletin, 
July 1990 ("the Barr article"). 

With this Amendment, Claims 19 and 29 have been amended to correct for typographical errors and 
to provide for proper antecedent basis for the term "network element," which appears in the bodies of 
the claims. No new matter has been entered by these amendments. Applicants have also amended 
the Specification to provide brief descriptions of FIGS. 8A-8F. Applicants respectfully traverse the 
remaining rejections of the claims and provide reasons as to why the pending claims are allowable 
over the cited prior art. Claims 1-35 are pending in the application. 

Response to the Rejections of Claims 26, 27, and 29-34. 

Claims 26, 27, and 29-34 were rejected under 35 U.S.C. § 102(a) as being anticipated by the 
Braun article. Claims 26, 29, and 32 are the independent claims in the rejected set. The Rejection is 
respectfully traversed. 

Response to the Rejection of Claim 26 

Among other elements, independent Claim 26 recites that a plurality of data objects 
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comprises "a value comprising a measured value of said asset data object for dynamically updating 
said value to said application program/ 1 The Rejection points to the phrase "bandwidth requested" 
on page 97, line 17 of the right-hand column as anticipating this element of Claim 26. Applicants 
respectfully disagree. This phrase refers to the amount of bandwidth that the user requests when the 
user requests the establishment of a virtual private network (VPN) connection. Braun's "bandwidth 
requested" does not refer to a measured value of an asset data object that is for dynamically updating 
to an application program, but rather to input data provided by the user. This is clear from the 
sentence at page 97, lines 8-12 of the right-hand column read in light of the two subsequent sentences 
at lines 13-20 of the same column. Accordingly, Braun's "bandwidth requested" does not anticipate 
this element of Claim 26, and the Rejection's prima facie reading of the Braun article does not 
anticipate Claim 26 since it does not contain all elements of the claim (see M.P.E.P. § 2131, "TO 
ANTICIPATE A CLAIM, THE REFERENCE MUST TEACH EVERY ELEMENT OF THE 
CLAIM"). Accordingly, Applicants respectfully request that this Rejection of Claim 26 and its 
dependent Claim 27 be withdrawn. 

Response to the Rejection of Claim 29 

Among other elements, independent Claim 29 recites the action of "selecting a real time 
variable to be dynamically monitored based on a legal agreement." The Rejection points to the 
phrase "the Service Level Specification must be established" on Braun's page 91, lines 39-40 of the 
right-hand column as anticipating this element of Claim 29. However, there is not sufficient 
information in the Braun article to determine if his service level specification is a legal agreement, or 
merely a technical specification {e.g., a set of instruction rules). More importantly, however, the 
action of "selecting a real time variable to be dynamically monitored" cannot legally be inferred from 
Braun's reference to "Service Level Specifications." To do so would be an impermissible reading of 
material into the Braun article. Accordingly, Braun's "Service Level Specifications" does not 
anticipate the above action recited by Claim 29, and the Rejection's prima facie reading of the Braun 
article does not anticipate Claim 29 since it does not contain all elements of the claim (see M.P.E.P. § 
2131). For this reason alone, Applicants respectfully request that this Rejection of Claim 29 and its 
dependent Claims 30-31 be withdrawn. 

As a further basis of traversal, independent Claim 29 also recites the action of "using said 
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measured real time variable, determining if a condition in said legal agreement is met." The 
Rejection points to the phrases "Security Associations (SA)" at page 91, line 1 1 of the right-hand 
column as anticipating this element of Claim 29. Applicants respectfully disagree. Braun's security 
association is not a legal agreement. Rather, as indicated at lines 12-13 of that column of the Braun 
article, Braun's security association defines which packets are to be sent through the VPN channels, 
and which encryption algorithms and corresponding encryption keys are to be used on the packets 
that go through the VPN channels. For this purpose, there is no need to measure a real time variable, 
and no need to determine if a condition in a legal agreement is met. Simply put, Braun's security 
association is an instruction guide. Accordingly, Braun's "Security Associations (SA)" does not 
anticipate the above action recited by Claim 29, and the Rejection's prima facie reading of the Braun 
article does not anticipate Claim 29 since it does not contain all elements of the claim (see M.P.E.P. § 
2131). For this reason as well, Applicants respectfully request that this Rejection of Claim 29 and its 
dependent Claims 30-31 be withdrawn. 

Response to the rejection of Claim 32 

Among other elements, independent Claim 32 recites "presenting said dynamic sales 
presentation on said computer display to a customer, said dynamic sales presentation, comprising a 
real time variable of said network." The Rejection points to the phrases "exchange variable" and 
"network packet" at page 91, line 7 of the left-hand column as anticipating this element of Claim 32. 
Applicants respectfully disagree. The network packet referred to in the Braun article is actually a 
container of data that is being transmitted through the virtual private network (VPN) connection; it is 
not a variable of the network, as recited by Claim 32. In addition, the Undersigned could not find 
any reference in the Braun article to "exchange variable." The Braun article does make reference to 
"Internet key exchange (IKE) protocol," but this is a protocol, not a variable of the network. 
Accordingly, Braun's "network packet" does not anticipate a real time variable of the network or the 
presentation thereof in a dynamic sales presentation, and the Rejection's prima facie reading of the 
Braun article does not anticipate Claim 32 since it does not contain all elements of the claim (see 
M.P.E.P. § 2131). For this reason alone, Applicants respectfully request that this Rejection of Claim 
32 and its dependent Claims 33-34 be withdrawn. 

As a further basis of traversal, independent Claim 32 also recites: "during said presenting, 
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updating said real time variable by measuring a network element of said network." The Rejection 
points to the phrases "packet encapsulation" at page 91, line 7 of the left-hand column as anticipating 
this element of Claim 32. Applicants respectfully disagree. The "packet encapsulation" referred to 
in the Braun article is actually a method of wrapping a data packet within a new data packet by 
adding a new header to the front of the packet (the addition of this new header is called 
"prepending"). This is done to transport the original data packet through the VPN connection. As 
indicated at page 91, lines 10-15 of the left-hand column, the new header is added to the original 
packet at the starting point of the VPN connection, and the added header contains the end-point 
address of the VPN connection. When the new packet arrives at the tunnel end-point, the new header 
is removed and the original packet forwarded based on the end-point address indicated by the header 
of the original packet. The content of the original packet is not changed, and is not measured. As 
such, the original packet is not a real-time variable of the network, as recited by Claim 32, and the 
action of encapsulating a packet within another packet is not the same as updating a real time 
variable because the content of the packet is unchanged and is not in need of being updated. 
Accordingly, Braun's "packet encapsulation" does not anticipate Claim 32's recitation of "updating 
said real time variable by measuring a network element of said network" during the dynamic sales 
presentation, and the Rejection's prima facie reading of the Braun article does not anticipate 
Claim 32 since it does not contain all elements of the claim (see M.P.E.P. § 2131). Applicants 
respectfully submit this as an additional basis for requesting that this Rejection of Claim 32 and its 
dependent Claims 33-34 be withdrawn. 

Response to the Rejections of Claims 1-3, 5-11, 13-25, 28, and 35 

Claims 1-3, 5-11, 13-25, 28, and 35 were rejected under 35 U.S.C. § 103(a) as being 
obvious over the Braun article in view of the Roseman patent. Claims 1, 10, 19, and 35 are the 
independent claims in the rejected set. The Rejection is respectfully traversed. 

For the benefit of the record, the Undersigned explains his understanding of the 
structure of the Rejection. The first part of the Rejection, which spans from page 5 through to 
the middle of page 8, provides a claim-by-claim listing of the Examiner's view as to which 
elements of the rejected claims are anticipated by the Braun article. Then, at the third complete 
paragraph on page 8, the Rejection provides the Examiner's view as to which claim elements the 
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Braun article fails to disclose. From the end of page 8 through to page 1 1, the Rejection then 
provides a claim-by-claim listing of the Examiner's view as to which elements of the Roseman 
patent can be combined with the Braun article to meet the complete set of limitations of each 
rejected claim. Finally, at the last paragraph on page 1 1, the rejection provides a motivation for 
making the prima facie combinations, which is "to efficiently manage the network data." 
Applicants first respond by showing that the proffered motivation to combine the Braun and 
Roseman references does not have a valid basis in the references themselves and in the prior art, 
and for that reason the Rejection of Claims 1-3, 5-11, 13-25, 28, and 35 cannot be legally 
sustained. Applicants then provide further reasons as to why the Rejection of independent 
Claims 1, 10, 19, and 35 should be withdrawn. 

The Proffered Motivation for the Combination of 
Roseman with Braun Does Not Have a Valid Basis 

In order to advance a prima facie obviousness combination of a primary reference and a 
secondary reference, there must be a proper and valid motivation for one of ordinary skill in the 
art to add the teachings of the secondary reference to the primary reference in order to make the 
combination. The changes to be made to the primary reference must derive from the 
straightforward incorporation of teachings from the secondary reference into the primary 
reference, and the changes must not destroy the functions, goals, or objectives of the primary 
reference. The motivation and the incorporation of teachings cannot be derived by hindsight 
knowledge of the claimed invention or of the Applicant's Specification. 

Applicants respectfully traverse the Rejection's proffered motivation for making the 
prima facie obviousness combination of Braun and Roseman as not having a valid basis in the 
Braun and Roseman references themselves, or in the prior art. The Braun article is focused on 
providing a system whereby a user can establish on-demand VPN service with on-demand VPN 
connections through a public packet switching network (Braun, page 93, bottom right-hand 
column, section entitled "A GENERIC QoS VPN MANAGEMENT ARCHITECTURE," 
through to the end of the article, and particularly page 95, right-column, section entitled "A 
PROTOTYPE IMPLEMENTATION OF A QoS VPN MANAGEMENT SYSTEM"). Braun 
does not indicate that a spreadsheet program would make the establishment of these items more 
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efficient or more manageable, thereby showing that the Rejection's proffered motivation does not 
have a valid basis. And while Roseman does use a "network" of programmable logic controllers 
(PLCs), there is no need in Roseman to establish on-demand VPN service or on-demand VPN 
connections for the PLCs since they are all located in a single factory in a private (non-public) 
environment, and since they are all interconnected with a conventional PLC bus cable, which is 
not a public switching network. This further shows that the Rejection's proffered motivation 
does not have a valid basis. 

Braun does discuss, at the right-hand column of page 94, having his topmost business 
layer provide service status information to the customer (lines 45-50), and having measurement 
information flowing from the bottom layer to the topmost layer (the layers are shown at the right 
in Fig. 2 of the Braun article). However, the information is compressed and abstracted as it 
moves up through the layers, and the information flow does not leapfrog across layers (Braun 
article, page 94, left-hand column, lines 7-13, and page 95, left-hand column, lines 2-6). This 
compression and layer-by-layer abstraction of information in the Braun system would clearly 
preclude a straightforward incorporation of the Roseman system into Braun's system by one of 
ordinary skill in the art, if not make it impossible. The lack of such a straightforward 
incorporation weighs heavily against the validity of any proffered motivation to combine the 
references, including that expressed by the Rejection. 

Moreover, the Undersigned is not aware of any prior art of record, or prior art in 
general, that would support the motivation proffered by the Rejection. In this regard, it not clear 
how Roseman's use of a spreadsheet to send control commands to a plurality of PLCs has any 
relationship, or provides any helpfulness, to Braun's tasks of establishing on-demand VPN 
service and establishing on-demand VPN connections. 

Pages 90 through 93 of the Braun article describe various prior art background areas 
related to his system, areas such as VPN enabling technologies, QoS support for VPNs, Traffic 
Engineering, Multiprotocol Label Switching, and Traditional IP Network Management. There 
Braun notes both the advantages and disadvantages of these areas, with many of the 
disadvantages being addressed by the abstraction and compression of commands and information 
as the commands and information move between Braun's layers. There is nothing in these 
sections of Braun that indicates or suggests that Roseman's spreadsheet system could be 
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integrated into the areas, or that it would have any substantive benefits if it were. 

For the above reasons, it is respectfully submitted that the Rejection's proffered 
motivation for making the prima facie obviousness combination of Braun and Roseman does not 
have a valid basis in the Braun and Roseman references themselves, or in the prior art. Because 
having a valid motivation is necessary to sustain an obviousness rejection (M.P.E.P. §2143.01), 
Applicants respectfully submit that the Rejection of Claims 1-3, 5-11, 13-25, 28, and 35 should 
be withdrawn. 

As further to Claim 1 , the Rejection points to the phrases "exchange variable" and 
"network packet" at Braun's page 91, line 7 of the left-hand column as anticipating the claim's 
element of "selecting a real time variable of said network element for dynamic monitoring in a 
cell on a spreadsheet" (page 5 of the Office Action). However, as indicated above, the network 
packet referred to in the Braun article is actually a container of data that is being transmitted 
through the virtual private network (VPN) connection; it is not a variable of the network, as 
recited by Claim 1. In addition, the Undersigned could not find any reference in the Braun 
article to "exchange variable." On page 9 of the Office Action, the Rejection states that 
"Roseman also teaches real time variable for dynamic monitoring in a cell or spreadsheet and 
displaying real time variable in said cell. . ." However, Roseman does not teach or suggest 
selecting a variable of a network element. 

Also, the Rejection of Claim 1 points to the phrase "packet encapsulation" at Braun's 
page 91, line 7 of the left-hand column as anticipating the claim's element of "measuring said 
real time variable of said network element" (page 5 of the Office Action). However, as indicated 
above, the "packet encapsulation" referred to in the Braun article is actually a method of 
wrapping a data packet within a new data packet by adding a new header to the front of the 
packet, and does not change the content of the original packet. Moreover, the encapsulation 
process does not "measure" the packet. In addition, the Roseman patent does not teach or 
suggest measuring a variable of a network element. 

Applicants respectfully submit these reasons as additional bases for requesting that the 
Rejection of Claim 1 and its dependent Claims 2-9 be withdrawn. 
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As further to Claim 10, Claim 10 recites actions that occur among three separate 
components: a network element, a server, and a client computer. The Roseman patent only has 
two components that could conceivably be corresponded to these components: Roseman's 
personal computer and one of his PLCs (Roseman's PLCs are intended to only talk to the 
Roseman's personal computer, not to one another). Roseman's PLC does not have sufficient 
functionality to act as a server, and it does not have sufficient functionality to act as a client 
computer that can display a spreadsheet. At best, Roseman's personal computer could only serve 
as the client computer or the server, not both. Thus, because the Roseman patent lacks all three 
components, it cannot meet all the elements of Claim 10. The Rejection of Claim 10 is difficult 
to follow, but it does appear to consider Roseman's personal computer to act as both the server 
and the client's computer. If so, it is respectfully submitted that this would be a highly strained 
reading of the Roseman patent, and an unfair and impermissible application of the Roseman 
patent against the claim. 

The Rejection does not rely upon the Braun patent to rectify the lack of a third 
component in the Roseman patent or, alternatively, the strained reading of the patent. However, 
presuming that it did, it is respectfully submitted that the combination of the Braun and Roseman 
references would lack a valid motivation for the reasons given above. 

Applicants respectfully submit these reasons as additional bases for requesting that the 
Rejection of Claim 10 and its dependent Claims 1 1-18 be withdrawn. 

As further to Claim 19 , the Rejection argues that Braun's page 93, lines 23-33 of the 
left-hand column, teaches the "live update module for sending changes to said measurable 
variable to said software" recited by Claim 19. From the entire reading of the claim, it is clear 
that the live update module sends changes in the measurable value to the software, such as when 
measurable value changes. Nonetheless, an amendment has been made to Claim 19 to make this 
even more clear. The amendment is supported by the description of live update module 734 in 
paragraph of [0049] of the present Specification. Accordingly, it is clear that the changes 
occurring in the measurable value are sent from the server to the software recited by Claim 19. 

It is respectfully submitted that lines 23-33 of the left-hand column of Braun's page 93 
does not teach or suggest a live update module for sending changes in a measurable variable to 
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software running on a client computer. While this section of Braun indicates that the SNMP 

allows monitoring of network elements, it clearly states that the SNMP allows pushing (i.e., 

sending) configuration information into networking devices. This configuration information is 

not a measurable variable or a change to a measurable variable. The Rejection makes a cryptic 

reference to "all broken device-specific networking functions outlined from Management 

Information Base." It is not clear what is meant by this statement. However, this passage from 

the Braun article states that: 

"The main advantage of SNMP is that it is open and widely adopted. 
However, SNMP does not support service management directly. The 
services have to be broken into device specific networking functions 
which are outlined in a management information base (MIB)." 

And it is clear that this passage does not teach or suggest the live update module recited by 

Claim 19. Moreover, since the "services" have to be broken into device specific networking 

functions, these networking functions are best seen as parts of services, not measurable variables 

or changes to measurable variables. 

Applicants respectfully submit these reasons as additional bases for requesting that the 

Rejection of Claim 19 and its dependent Claims 20-25 be withdrawn. 

As further to Claim 35 , the Rejection points to the phrases "exchange variable" and 
"network packet" at Braun's page 91, line 7 of the left-hand column as anticipating the claim's 
element of "means for selecting a real time variable of said network element, wherein said real 
time variable is dynamically monitored in a cell on a spreadsheet" (page 8 of the Office Action). 
However, as indicated above, the network packet referred to in the Braun article is actually a 
container of data that is being transmitted through the virtual private network (VPN) connection; 
it is not a variable of the network, as recited by Claim 1. In addition, the Undersigned could not 
find any reference in the Braun article to "exchange variable." On page 1 1 of the Office Action, 
the Rejection states that "Roseman teaches real time variable is dynamic monitored in a cell on a 
spreadsheet. . ." However, Roseman does not teach or suggest selecting a variable of a network 
element. 

Also, the Rejection of Claim 35 points to the phrase "packet encapsulation" at Braun's 
page 91, line 7 of the left-hand column as anticipating the claim's element of "means for 
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measuring said real time variable of said network element" (page 8 of the Office Action). 



However, as indicated above, the "packet encapsulation" referred to in the Braun article is 
actually a method of wrapping a data packet within a new data packet by adding a new header to 
the front of the packet, and does not change the content of the original packet. Moreover, the 
encapsulation process does not "measure" the packet. In addition, the Roseman patent does not 
teach or suggest measuring a variable of a network element. 

Applicants respectfully submit these reasons as additional bases for requesting that the 
Rejection of Claim 35. 

Response to the Rejection of Claims 4 and 12 

These claims were rejected for the same reasons as their base independent claims, 
further in view of the Barr article. It is respectfully submitted that the Barr article does not 
rectify the deficiencies in the rejections of the base independent claims (Claims 1 and 10), and 
that Claims 4 and 12 are therefore allowable for the same reasons as are Claims 1 and 10. 



In view of the remarks made above, Applicants respectfully submit that the application 
is in condition for allowance and action to that end is respectfully solicited. If the Examiner 
should feel that a telephone interview would be productive in resolving issues in the case, the 
Examiner is invited to telephone the undersigned at the number listed below. 



CONCLUSION 



October 24, 2005 



Respectfully submitted, 



Sheppard Mullin 

Richter & Hampton LLP 

Four Embarcadero Center, 17-th Floor 

San Francisco, CA 94111 

Tel: (415)774-3203 

Fax: (415)434-3947 
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